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(54) Digital system simulation 

(57) A simulator for a digital system comprises a 
simulation model, an event queue for scheduling 
changes to the state of the simulation model at specified 
times, and a separate delta queue, for scheduling 
changes to the state of the simulation model that are to 
take place instantaneously. The use of separate event 
and delta queues facilitates optimization of the queuing. 
The simulation model comprises a number of replacea- 
ble parts, each of which contains and is responsible for 
managing its own state information. The event and delta 
queues contain references to the parts of the model for 
which changes of state are scheduled, without contain- 
ing the actual values of those changes of state. 
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Description 

Background to thp InvAnfinn 
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tern, so as to increase the speed of simulation. 
Summary of the Invpntinn 



This invention relates to simulation of digital sys- 
tems. The invention is particularly, although not exclu- 
sively concerned with simulating complex logic 
networks, such as are found in electronic computers. 

Conventional simulators use a queue to schedule 
changes to the state of the simulated system. Whenever 
It IS determined that the state is to change, a record con- 
taining the new state value is added to the appropriate 
posmon of the queue. In operation, the queue is 
scanned sequentially, to simulate the passage of time 
and. as each record is scanned, the new state values 
speafted by that record are set. 

The VHOL simulation language [ANSI/IEEE Stand- 
ard 10761 uses signals to propagate changes of state 
around the simulation model. Signals are classified as 
unresoh/ed and resolved. Unresolved signals are those 
that have only one driving source, while resolved sig- 
nals have more than one driving source. A resolution 
process ts used to handle resolved signals, so as to 
resolve the values from the different sources. 

Unresotved signals may be either event-based or 
delta-based Event-based signals have explicit time 
delays associated with them. Delta-based signals, on 
the other hand, represent changes that are assumed to 
take place instantaneously; i.e. they do not have any 
explicit time delays associated with them. Delta-based 
signals are used to ensure order independence for con- 
current processes, and to ensure that changes to the 
signal value take place only when all the concurrent 
processes have conpleted their execution for the cur- 
rent tme unit. In the case of an event-based signal, a 
record is added to the queue at the appropriate time 
position, taking account of the time delay for that signal 
In the case of a delta-based signal, a record is added at 
the position in the queue corresponding to the current 
simulation time. 

Conventional VHDL simulators use a centralised 
kernel to control the operation of the simulation model. 
Such a kernel requires a fixed data format, to which all 
data types used in the simulation must conform, to rep- 
resent changes of state of the model, and requires a 
range of generalised routines for handling all these 
changes. 

A problem is that when the simulated network is 
large and complex, the simulation can be very slow and 
hence take a very long time to run. Also, the complexity 
of the kernel is a problem, if it is required to maintain a 
high level of performance while enabling the kernel to 
deal with each data type in whatever form. Every adjust- 
ment to the kernel becomes performance-critical and 
some data types cannot be added for fear of losing sim- 
ulation performance. 

The object of the present Invention is to provide a 
way of improving the performance of a simulation sys- 



5 According to the invention a simulator for simulating 
a digital system comprises a simulation model, an event 
queue for scheduling changes to the state of the simu- 
lation model at specified times, and a separate delta 
queue, for scheduling changes to the state of the simu- 
10 lation model that are to take place instantaneously. 

It will be shown that the use of separate event and 
delta queues in this way makes it possible to perlbrm a 
number of optimizations that would not be possible in a 
conventional simulator with a single queue for both 
15 events and deltas. 

Preferably, the simulation model comprises a 
number of replaceable parts, each of which contains its 
own state information and is responsible for managing 
its own state information, and the event and delta 
so queues contain references to the parts of the model for 
which changes of state are scheduled, without contain- 
ing the actual values of those changes of state. 

It will be shown that this makes possible a number 
of further optimizations that would not be possible in a 
25 conventional simulator with a centralised kernel. 

Brief Descriptinn of the Drawingg 



Figure 1 is a schematic block diagram of a compu- 
ter system embodying a simulator in accordance 
with the invention. 

Figure 2 is a schematic diagram of a simulation 
model. 

Figure 3 Is a flow chart of a top-level model used in 
the simulator. 

Figure 4 is a flow chart of a pop.deltasQ function. 
Figure 5 is a flow chart of a pop_eventsO function 
Figure 6 is a flow chart of an entry() function. 
Figure 7 is a flow chart of a send_evemO function. 
Figure 8 is a flow chart of a f lre_eventO function. 
Figure 9 is a schematic diagram of part of the sim- 
ulator. 

Description nf an P nbodiment nf the Invention 

One simulator in accordance with the invention will 
now be described by way of example with reference to 
the accompanying drawings. 

so Overview of the simulator 
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Referring to Figure 1. the simulator comprises a 
general-purpose computer 10. which contains a number 
of software components, including a simulation model 
55 11 . a top-level model 1 2. an event queue 13. and a delta 
queue 14. 

The simulation model 1 1 simulates a specific logic 
network. The top-level model 12 provides a framework 
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not contain any event-based signal objects. In this 
case therefore, there is no event queue overhead. 

Single event queue: this is chosen if the model con- 
tains only one event-based signal object, and this s 
signal object holds only one state change at a time. 
This is the fastest form of queue, since no Insertion 
operation Is required. 

Multiple event queue: this option is chosen when 10 
the model contains more than one event-based sig- 
nal object, or contains a single event-based signal 
object that can contain more than one state 
change, and when the range of time delays is rela- 
tively small. 15 

Multiple event, large time base range queue: this is 
the slowest form of queue, but is capable of han- 
dling a relatively large range of time delays. 

20 

(Step 303) An initial set of delta records is inserted 
on the delta queue. 

(Step 304) These initial delta records are then 
popped off the delta queue, so as to perform an ini- 25 
tial setting of the signal values. This uses a 
popJnitialisation_deltas() function. 

(Step 305) Each process object in the model is ini- 
tialised, by calling its entry() function. This may 30 
result in further deltas being generated and 
inserted on the delta queue for the next delta time. 

(Step 306) The current event time and current delta 
time are both reset to zero. 35 

(Steps 307 - 309) The top-level model then enters a 
main loop, in which the pop_events 0 function and 
the pop_deltas0 function are called alternately. 
This loop continues until either the event queue 40 
becomes empty, or until the simulation time 
reaches a specified simulation end time. 

Pop__deltasO 

45 

The pop_deltas() function will now be described 
with reference to Figure 4. 
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called. The change_state() function updates the 
state of the referenced signal object, by setting its 
old_state value equal to its new_state value. This 
loop is repeated until the record pointer is null, indi- 
cating that the last record in the delta queue has 
been reached. 

(Step 406) The queue record pointer is reset to the 
first record in the delta queue. 

(Steps 407 - 409) A loop is performed in which each 
record in the delta queue is selected in turn. The 
selected record is removed from the delta queue, 
and the f ire_eventO function of the signal object ref- 
erenced by this record is called. This loop is 
repeated until ail the current records in the delta 
queue have been removed. 

The f ire_event() function may result in further delta 
records being created and added to the end of the delta 
queue. These new delta records are not processed dur- 
ing this run of the pop_deltas() function; they are proc- 
essed at the next delta time (i.e. during the next run of 
the pop_deltasO function). 

The popjnitialisation_deltas() function is similar to 
the pop_deltas function, except that steps 406-409 are 
omitted. Hence, in this case, the f ire_event() function is 
not called, and so no propagation of signals takes place. 

Pop_everrtsO 

The pop_eventsO function will now be described 
with reference to Figure 5. 

(Step 501) If the event queue is empty, the function 
returns. Otherwise, it proceeds to step 502. 

(Step 502) A check is made to determine whether 
event_time value of the first record on the event 
queue is past (i.e. greater than) the specified simu- 
lation end time. If so, the function returns. 

(Step 503) A queue record pointer is set to point to 
the first record in the event queue, and the current 
event time is set equal to the event_time value of 
this record. 

(Steps 504 - 506) A loop is performed in which each 
record on the event queue is selected in turn. For 
each of these records, the change_stateO function 
of the signal object referenced by the record is 
called. The change_state() function updates the 
state of the referenced signal object, by setting its 
the old_state value equal to its new_state value. 
This loop is repeated until the eventjme value of 
the selected record is greater than current event 
time. 



(Step 401) If the delta queue is empty, the function 
returns. OthenA^ise, it proceeds to step 402. so 

(Step 402) A queue record pointer is set to the first 
record in the delta queue. 

(Step 403 - 405) A loop is performed, in which each 55 
record in the delta queue is selected in turn. For 
each of these records, the change_state() function 
of the signal object referenced by this record is 
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(St^ 507) The queue record pointer is then reset to 
the first record in the event queue. 

(Steps 508 - 510) A loop is performed in which each 
record in the event queue is selected in turn The 
selected record is removed from the event queue 
and the f ire.eventQ function of the signal object ref- 
erenced by this record is called. This loop is 
repeated until the eventjme value of the selected 
record is greater than current event time. 

EntryO function 

Each process object has its own entryQ function 
specinc to that process object. Figure 6 shows the 
entryO function of a typical process object. 

(Step 601) The function reads the old_state values 
of any input signal objects, performs user-defined 
processing operations, and updates the new_state 
value of any output signal objects. For example in 
Figure 2, the process object P2 reads the old_state 
value of SI. and updates the new_state value of 
S2. The updating of the new_state value sets the 
altered flag of the signal object to TRUE. 

It should be noted the old_state of the output signal 
object IS not updated at this stage. Hence, any ottier 
process objects that are fired at the same delta time (or 
event time) will still use the same old_state value. The 

n^Tu ''f'^ "P^^*^ tf^e next run of the 
pop_deltasO or pop_eventsO function, as described 

(Step 602) After completion of all user-defined 
processing operations, the entryQ function calls the 
send_eventO function of every signal object whose 
state It may possibly have updated during the 
processing. 
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change to the signal object has already been 
scheduled on the event queue for exactly the same 
time as the change currently being processed This 
step involves checking whether eventjime (i e the 
event time at which the signal is scheduled to 
change) is greater than the value of 
last_event_time for this signal otjject. If not, then a 
change has already been scheduled, and no further 
action is taken by this function. 

(Step 705) Assuming that all the above checks are 
satisfactory, the value of last_event_time for the sig- 
nal object is set equal to eventjime. The change is 
then scheduled, by calling push_event(this 
event_t.me). where "this" represents a pointer to 
this signal object. This adds a new record to the 
appropnate position in the event queue. 

H can be seen that the tests described above 
ensure that a signal is queued only if its values have 
changed and if a change for that signal has not already 
been queued. This reduces the number of queuing 

STfn ^"l^^"'^^ f^e'PS to '"iprove the running 
speed of the model. 

As stated, the above description of Figure 7 
a^umes that the signal object is event-based. If it were 
delta*ased. Steps 74 and 75 would be replaced by 
step 704a as follows. m cu uy 

(Step 704a) The change is scheduled, by calling 
push_delta(this). where "this" represents a pointer 
to this signal otjject. This adds a new record to the 
end of the delta queue. 

35 Fire_eventO 

signa^oSi?.''"' °^ ^ 
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Send_eventO 

Rgure 7 shows the send_event Q function of a typ- 
ical signal object. It is assumed in the following descrip- 
tion that the signal object is event-based. 

(Step 701) The function first checks whether the 
altered flag of the signal object is TRUE. If so the 
function proceeds to step 702. othen«,ise. it returns. 

(Step 702) The value of the altered flag for the sia- 
nal object is reset to FALSE. 

(Step 703) The function then checks whether the 
new_state value of the signal object is equal to its 
old_state value. If so, the function returns. 

(Step 704) The function then checks whether a 
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(Step 801) The function first checks whether the 
procjjtr for the signal object is null. If procotr is 
null, this means that the signal object does not have 
any dependent process objects, and so no further 
action IS taken by this function. 

(Step 802) Assuming that proc_ptr is non-null the 
entryO function of the dependent process pointed 
to by proc_ptr is called. 



50 Operatton 



The operation of the simulator will now be illus- 
K^' ol to Figure 9, which shows process 

ol)|ects PI . P2. signal object SI . and the event queue It 
IS assumed that Si Is event-based. 

When the entryQ function of Pi runs, it updates the 

IT/*^*^ r^'y^ °* SI. It then calls the 

send_eventO function of Si. after it has performed any 
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Other user -defined processing. 

The send^eventO function calls the push_eventO 
function of the event queue, which causes an event 
record to t>e added to the event queue, for a specified 
event time 

When the specified event time arrives, the 
pop_events() furction removes this record from the 
event queue, and calls the change_stateO function of 
Si . This causes the old_state of SI to be set equal to its 
new_state Poo.events then calls the f ire_eventO func- 
tion of SI This calls the entry() function of the depend- 
ent process object P2 

In summary d can oe seen that the effect of this is 
that a signal & comrrxjnicated from PI to P2, with a 
specified de*dy 

Discussion 

An irrportarr tc^ature of the simulation technique 
described atxve c r»e jso o* separate event and delta 
queues. The two d^f^erem tx ms of time, delta time and 
event time, have cune^ertt lorms of queuing action as 
well as different optimi/ations. and so the use of sepa- 
rate event and rt»*na c^i^x^ makes it much easier to 
optimize the qiJ<H«r*g Actions For example, the form of 
the event queue can t>e optim/ed as described above. 

Another importartt feature of the simulation tech- 
nique is that each changeable part of the simulation 
model is irrplemented as a separate object, and each 
object is respor^We •or hancfltr>g its own changes of 
state. As a result the state of each part can be held in 
an optimum format, rathec than having to use a stand- 
ard format, as is requwed m converTtional kernel-based 
simulators. Moreover, the routines needed to change 
the state of a modei part can be specifically designed 
for that part, rather than relying on a generalised routine 
in a kernel. This allows a large number of discrete opti- 
mizations to be appi>ed to the individual model parts so 
as to increase the speed of the simulation. 

Since each part of the model controls its own state, 
the queues do not neeo to hold the actual values of the 
changes of state, instead they can simply hold refer- 
ences to the model par whose states are scheduled to 
change. This greatly sinx5lif»es the queuing actions, 
since values do not have to be copied to and from store, 
and complex data structures can t>e dealt with by their 
owning parts, rather than by generalised queuing rou- 
tines. This leads to further improvements in efficiency. 



Claims 

1 . A simulator for simulating a digital system, the sim- 
ulator comprising a simulation model, an event 

5 queue for scheduling changes to the state of the 
simulation model at specified times, characterised 
by a separate delta queue, for scheduling changes 
to the state of the simulation model that are to take 
place instantaneously. 

10 

2. A simulator according to Claim 1 wherein the simu- 
lation model comprises a number of replaceable 
parts, each of which contains its own state informa- 
tion and is responsible for managing its own state 

75 information. 

3. A simulator according to Claim 2 wherein the event 
and delta queues contain references to the parts of 
the model for which changes of state are sched- 

20 uled, without containing the actual values of those 
changes of state. 



A simulator according to Claim 2 or 3 wherein the 
parts of the model include process objects and sig- 
nal objects. 
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A simulator according to Claim 4 wherein each of 
the signal objects directly drives at most one of the 
process objects, and including at least one split 
process positioned between a signal object and a 
plurality of process objects, for allowing that signal 
object to drive the plurality of process objects indi- 
rectly. 

A simulator according to any preceding claim 
including means for selecting an optimum form of 
said event queue. 

A simulator according to any preceding claim 
including means for checking that a state value has 
actually changed, and that this change of state has 
not already been added to the event queue or delta 
queue, before adding that change to the event 
queue or delta queue. 



Some possible modif^ca^on$ 



It will be appreciated that many modifications may 
be made to the system described above without depart- 
ing from the scope of the present invention. For exam- 
ple, the queues may be based on timing loops, as 55 
described in our US Patent no 5157620, rather than 
being constructed as linked lists. 
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